1. Field of the Invention
Embodiments of the present invention generally relate to an asymmetric logical unit access based storage system and, more particularly, a method and apparatus for providing dynamic multi-pathing (DMP) for an asymmetric logical unit access (ALUA) based storage system.
2. Description of the Related Art
ALUA based storage systems use multiple processors, or controllers, for controlling access to a plurality of disks that are arranged in at least one array in a storage system. The processors receive I/O traffic (also referred to as I/O's or read/write commands) from a host through a storage area network (SAN). The host communicates with the processors via the processors' ports. Usually, a processor is configured as an “owner processor”, which is the owner of a specific disk array. Another processor is configured as “standby processor”, which is a backup processor that is available to perform owner functions if the owner processor were to fail. The owner processor executes data access requests within I/O traffic from specific host(s). The owner processor processes the host's I/O traffic commands to/from the disk array it owns. The owner processor may “own” a portion of the disk array, while another processor may “own” another portion of the same disk array. Thus, the owner processor can be a standby processor for a portion of the array it does not own.
Upon a failure condition within the SAN, where the communication paths to the owner processor ports are blocked or otherwise have failed. The host uses dynamic multi-pathing (DMP) to re-route the I/O traffic intended for the owner processor to the standby processor. The re-routed I/O traffic is directed to the standby processor utilizing the communication ports of the standby processor.
In a non-ALUA-based storage system, upon failure of a path to an owner processor (i.e., an optimized path), the DMP process detects the failure and prepares to utilize the standby processor (i.e., an unoptimized path). Upon path failure, some I/O requests may be pending in a queue of the owner processor or otherwise in transit to the owner processor via the optimized path. When new I/O requests are issued to the standby processor via the unoptimized path, the storage system will recognize the failover and flush the owner processor cache to the standby processor; thus, ensuring that cache information is available for use by the standby processor in the same manner as the owner processor. If, after the cache flush, the owner processor executes an I/O request from the owner queue, the storage processor will flush the standby processor cache back to the owner processor. Then, when a new I/O arrives at the standby processor, the owner cache is flushed to the standby processor. This “ping-ponging” of cache flushing continues until the owner queue is empty. Such “ping-ponging” dramatically impacts the speed of the storage system. To avoid ping-ponging in a non-ALUA storage system, the DMP process waits for all queued and in transit I/O requests to be completed by the owner processor before failing over to the standby processor, i.e., the DMP process waits for the I/O requests to be returned—either a write acknowledgement or read data. The need to wait for completion of the I/O requests delays failover and impacts the availability of the storage system.
In an ALUA-based storage system, where ping-ponging does not occur because cache flushing is delayed by the failover process, upon optimized path failure, the multipathing driver also waits for I/O requests previously issued to the owner processor to clear before issuing I/O requests to the standby processor via the unoptimized. The storage system will swap the standby and owner processors after the system detects no activity from the owner processor and the I/O requests are being sent to the standby processor for a pre-defined period of time, e.g., two minutes. Other failover criteria might include the number of I/O bytes or volume of I/O bytes sent to the standby processor. Alternatively, after waiting for the pre-failure I/O requests to clear, failover may be initiated by the host manually issuing a command to cause the storage system to switch processors. The completion of the failover process is delayed by the amount of time taken for the pre-failure I/O requests to clear plus the time required for the storage array to swap processors.
In both non-ALUA based systems and ALUA-based systems, there is a significant delay between initiation of a failover and the completion of the failover. This delay may cause application process delays, bottlenecks in storage access, I/O traffic delays for all hosts that access the storage system, and system or process failure.
Therefore, there is a need for providing improved dynamic multi-pathing to alleviate the failover delay.